Skip to content

Add support for multiple schedulers #1781

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 12 commits into from
Closed

Conversation

brson
Copy link
Contributor

@brson brson commented Feb 8, 2012

This series adds support to the kernel for dynamically adding and removing schedulers then adds a single user-visible function, task::spawn_sched for spawning a task into a new scheduler. I have not implemented the full design for first-class schedulers, and think I may let this sit as-is for awhile while we review what we want the core::task API to look like (it's quite a mess these days).

For the most part this is not that interesting, but commits bde9385, 0f4ca21, and 36d5181 make big changes to the scheduler and task lifecycle and synchronization protocols to eliminate races between scheduler and task destruction and allow schedulers to be destroyed while the kernel is running. It's a little mind-bending, with a lot of events happening on various threads, and I probably can't explain how the kernel/scheduler/task_thread/tasks cooperate to shutdown the kernel without tracing through the code, but I left lots of comments.

This change also breaks rust_kernel::fail (the function that kills all tasks) even worse than before. It's very racy, but doesn't break any existing tests.

I'm doing some stress tests now to make sure things are still reliable.

brson added 12 commits February 7, 2012 22:12
Instead of joining on the scheduler threads, instead keep a count of active
schedulers. When there are no more schedulers raise a signal for the main
thread to continue.

This will be required once schedulers can be added and removed from the
running kernel.
This will be needed once we support dynamically changing schedulers.
This is in preparation for giving schedulers their own life cycle separate
from the kernel.

Tasks must be deleted before their scheduler thread, so we can't let the
scheduler exit before all its tasks have been cleaned up. In this scheme,
the scheduler will unregister tasks with the kernel when they are reaped,
then drop their ref on the task (there may still be others). When the task
ref count hits zero, the task will request to be unregistered from the
scheduler, which is responsible for deleting the task.

Instead of having the kernel tell the scheduler to exit, let the scheduler
decide when to exit. For now it will exit when all of its tasks are
unregistered.
This function creates a new scheduler with a specified number of threads and
immediately executes a task on it. The scheduler is configured to terminate
when the task dies. This is the minimum API necessary to enable blocking C
calls.
@brson
Copy link
Contributor Author

brson commented Feb 9, 2012

Thanks! Merged.

@brson brson closed this Feb 9, 2012
xFrednet pushed a commit to xFrednet/rust that referenced this pull request May 21, 2022
New lint: [`derive_partial_eq_without_eq`]

Introduces a new lint, [`derive_partial_eq_without_eq`].

See: rust-lang#1781 (doesn't close it though).

changelog: add lint [`derive_partial_eq_without_eq`]
Kobzol pushed a commit to Kobzol/rust that referenced this pull request Dec 30, 2024
bors pushed a commit to rust-lang-ci/rust that referenced this pull request Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant